Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

這系列文源自這幾年在團隊裡導入 AI Coding 之後，一路踩雷、修正、再踩雷的真實過程。把這些收斂出來的方法整理成文，也許對正在煩惱同樣問題的你會有些幫助。

就當作是一份邊做邊記的工程筆記吧！

本篇是 當 AI 加入團隊：打造可審查、可驗證、會自我改善的 AI 開發工作流 系列文的 EP05。

workflow 一旦真的開始被使用，很快就會撞到一個實務問題。

任務執行過程中會產生日誌、下載檔、暫存憑證、工作資料夾——這些東西不應該混進共用的規則 repository 裡。

想像一下，如果某次任務下載的日誌裡剛好夾帶了一組帳密，而這份日誌又被順手 commit 進了大家共用的工作流 repo...

這種事不需要發生第二次，光 "想" 就覺得毛骨悚然。

所以在很前期時，早就定下一條規則：規則的來源（source）跟任務的產物（runtime）必須是兩個世界。

%USERPROFILE%\.aiorchestrations\      ← 任務產物放這裡，不進版控
├── artifacts\
├── downloads\
├── logs\
└── workspaces\

AIOrchestrations\ (Git repo)    ← 只放審查過的規則
├── workflows\
├── skills\
└── knowledge\

上面的四個資料夾都是某一次任務的副產品：跑出來的證據、下載下來的日誌、執行過程的紀錄，以及臨時的工作目錄。

下面的 Git repo 則只收審查過、接下來還要被其他使用者(無論是 "人" 或是 "Agent") 再重複使用的。

這個邊界同時解決兩件事：

1. 降低敏感資料被提交的風險——日誌、cookie、下載檔天生就不該出現在共用歷史紀錄裡。
2. 避免共用文件被某次任務的暫存內容污染——今天這個任務產生的雜訊，不該變成明天所有人都要讀到的「規則」。

靠人記得清暫存，遲早會漏。所以我們把清理暫存資料寫成了一支腳本，讓「任務結束後清乾淨」成為可以固定執行的一步，而不是每次都要靠人想起。

有了這條界線之後，下一個問題自然浮現：AI 要怎麼寫程式、怎麼改東西，才不會每次都亂加東西或亂改別人的風格？

下一篇來談這個。